System and method for determining a process flow of a software application and for automatically generating application testing code

ABSTRACT

A computer-implemented method of mapping a process model of a software application executed by a hosting platform. A series of actions taken by a user with respect to user interfaces generated by the software application are simulated through one or more application programming interface (API) calls. The user interfaces include a form and the series of actions includes opening the form. A plurality of user interface fields of the form are then identified through one or more other API calls executed while impersonating a session of a user under test. At least some of the user interface fields are set to known values and the form is submitted to the software application after the fields have been set. Changes to field-related and record-related information resulting from the submission are then gathered and a process model of the software application is determined based upon the gathered information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the priority benefit, under 35 U.S.C. 119(e), ofU.S. Application No. 62/778,170, entitled “SYSTEM AND METHOD FORDETERMINING A PROCESS FLOW OF A SOFTWARE APPLICATION AND FORAUTOMATICALLY GENERATING APPLICATION TESTING CODE”, and filed on Dec.11, 2018. The aforementioned application is incorporated herein byreference in its entirety.

BACKGROUND

Software as a service platforms or PaaS, allow customers to implement anapplication or business process as a collection of database schemas withassociated views and rules for behavior of the user interface andside-effects for records/objects in the database related to actionstaken in the user interface.

There exist two vectors for changes to applications, explicit changes tothe application and changes to the SaaS platform. Changes to the SaaSplatform are authored by the vendor of that SaaS platform while changesto the application itself are authored by the customers of the vendorwho have implemented their organization's specific processes on the SaaSplatform. Once an application has been implemented on a SaaS platformthe general expectation is that the application should continue tobehave in the way it was implemented even as the platform itself isupgraded.

SaaS vendors have policies in place that make upgrades mandatory forcustomers. This is because they generally encourage customers to utilizenewer code versions in order to ensure that customers are running withfixes for security vulnerabilities, that customer support organizationsare not burdened with supporting old versions and that customers can buynew products only compatible or available with newer versions of theplatform.

Every upgrade to the SaaS platform by the vendor poses risk ofregression for customers utilizing the platform. A regression can resultbecause a net-new defect is present in the new version of the SaaSvendor's platform but also for more subtle reasons. Even if the SaaSvendor just changes behavior this will manifest as a defect for thecustomer if they have come to rely on the old behavior. Changes toplatform API's may make a customer's code incompatible with the newrelease thus resulting in errors and/or changes in application behavior.Additionally, depending on the ways in which a SaaS vendor exposesextensibility points in their platform there are additional risks. Thevendor of the platform may allow modification to their out-of-the-boxcode, that defines platform or base application functionality. If so,when changes are made by the SaaS vendor it may necessitate, on the partof the customer, doing a code merge. If the merge is not performedcorrectly it can result in regression. Doing these types of merges iserror prone. The difficulty is compounded by the reality that the personmerging the code didn't write the new version coming from the SaaSvendor but also oftentimes may not have written the customization to thevendors code or even be familiar with its intent.

Customers of a SaaS platform often implement significant functionality.However, such customers generally do not utilize automated tests thatwould help them detect unintended consequences of changes they areexplicitly making to their implementation or applications. Creatingautomated tests that essentially would just describe what they currentlyhave is quite difficult and time-consuming. While users may be using theapplication every day to fulfill their duties, the administrators anddevelopers of the SaaS platform at that company may not have sufficientknowledge of what was originally implemented and what behaviors theusers rely on. The individuals who implemented the application may notwork at the company any more or may have been a consultant who neverworked at the company. Just discovering this information by analyzingcode, interviewing users or documenting current behavior, as aprerequisite to writing good automated tests, is likely to be timeconsuming to the point of being cost prohibitive.

SUMMARY

An effective way to manage the risk associated with the constant changesto applications running on a SaaS platform or to the platform itself isthrough testing. Only through effective testing can it be ensured thatapplications running on the PAAS are running as expected.

A system which automates any part of this testing can providesignificant value. Once the application is in production, getting usedevery day by users, current functionality needs to be maintained.Disclosed herein is a system that describes current functionalitypre-change and then validates that the functionality still exists. As aconsequence, the system of the disclosure is able to streamline theheavy burden of manual testing or manual creation of automated tests.Applications developed on a PAAS or other software framework lendthemselves to this type of testing because of the separation of platformand application functionality. Business process is implemented as acomposition of platform metaphors for common types of process: a formfield is present in a particular view, required under certain conditionsor maybe read-only. When a form is submitted with some arbitrary list ofvalues set then business logic implemented by a customer states otherrecords are inserted or fields set. These rules constitute thecustomer's business process or process model, which is generally desiredto be maintained after the upgrade of the SaaS platform. Such rules arediscoverable and describable in accordance with the teachings herein.Finally, the rules defining the process model are testable if describedbefore and after the change and then compared in accordance with thepresent disclosure.

Although conventional automated tests may be manually created by testingengineers, by automating not just test execution but also the generationof the tests it is possible to reduce the work necessary to test achange. As a consequence, the time of testing professionals may bereallocated to other types of testing, thus resulting in greater overallcoverage and reduced risk of regressions in the software applicationsbeing tested.

In one aspect the disclosure is directed to a computer-implementedmethod of mapping a process model of a software application executed bya hosting platform where the software application is based on aplurality of records. The method includes simulating, through one ormore application programming interface (API) calls, a series of actionstaken by a user with respect to user interfaces generated by thesoftware application The user interfaces include at least a form and theseries of actions includes opening the form. The method further includesidentifying, through one or more other API calls executed whileimpersonating a session of a user under test, a plurality of userinterface fields of the form. The series of actions further includessetting at least some of the user interface fields to known values andsubmitting the form after the fields have been set. Field-relatedinformation resulting from the setting of the user interface fields isthen gathered. Record-related information corresponding to one or moreeffects on the plurality of records resulting from the submission of theform is also gathered. The process model of the software application isthen determined based upon the field-related information and therecord-related information.

In one implementation the act of identifying the user interface fieldsincludes identifying one or more visible fields, one or more mandatoryfields, and one or more read-only fields. This may further includeidentifying one or more available actions and may also includeidentifying current field values of the user interface fields.

The method may include identifying the mandatory fields included withinthe user interface fields and setting only the mandatory fields to knownvalues.

The simulated series of actions may be included within a plurality ofscenarios, each of the plurality of scenarios being automaticallygenerated based upon one of a plurality of scenario specifications. Atleast one of the scenario specifications may include informationspecifying which objects of the software application are to be testedwith respect to at least one of a set of users or a set of user groups.

In a particular implementation the known values to which the userinterface fields are set are obtained from historical data relating toprior usage of the software application.

The disclosure also relates to a computer-implemented method ofautomated testing of a software application executed against a hostingplatform. The method includes determining a process model of thesoftware application based upon user interface (UI) field-relatedinformation and record-related information. This information is obtainedby simulating, through one or more application programming interface(API) calls, a series of actions taken by a user with respect to one ormore user interfaces generated by the software application whenexecuting on a first version of the hosting platform.

A test of the software application is then automatically generated basedupon the process model. The software application may then be tested inaccordance with the test when the software application is executing on asecond version of the hosting platform.

In one implementation of the automated testing method, the one or moreuser interfaces utilized during the simulation include at least one formand the series of actions includes opening the form.

The stage of determining the process model of the software applicationmay involve performing a number of tasks. For example, a plurality ofuser interface fields of the form may be identified through one or moreother API calls. In this case the series of actions further includessetting one or more of the user interface fields to known values andsubsequently submitting the form. Field-related information resultingfrom the setting of the user interface fields may then be gathered. Inaddition, record-related information corresponding to one or moreeffects on the plurality of records resulting from the submission of theform may also be gathered.

In one implementation of the automated testing method, the act ofidentifying the user interface fields includes identifying one or morevisible fields, one or more mandatory fields, and one or more read-onlyfields. This may further include identifying one or more availableactions and may also include identifying current field values of theuser interface fields.

The automated testing method may include identifying the mandatoryfields included within the user interface fields and setting only themandatory fields to known values.

The simulated series of actions may be included within a plurality ofscenarios, each of the plurality of scenarios being automaticallygenerated based upon one of a plurality of scenario specifications. Atleast one of the scenario specifications may include informationspecifying which objects of the software application are to be testedwith respect to at least one of a set of users or a set of user groups.

In a particular implementation of the automated testing method, theknown values to which the user interface fields are set are obtainedfrom historical data relating to prior usage of the softwareapplication.

The automated testing method may include executing a plurality ofpass/fail tests. The testing method may further include (i) recordingtest results resulting from the testing of the software application, and(ii) detecting a regression in the software application by identifyingone or more differences between the test results and initial simulationresults comprised of the UI field-related information and therecord-related information.

BRIEF DESCRIPTION OF THE DRAWINGS

The present application may be more fully appreciated in connection withthe following detailed description taken in conjunction with theaccompanying drawings, wherein:

FIG. 1A illustratively represents an exemplary architecture of a testgeneration system configured to automatically test an applicationwritten on a SaaS platform.

FIGS. 1B and 1C illustrate an exemplary process flow associated with thetest generation system of the present disclosure.

FIG. 2 is a diagram of an exemplary architecture of a PaaS environmentlacking constraints on hosting arbitrary code or custom applications.

FIG. 3 is a diagram of an alternative exemplary architecture of a PaaSenvironment that is configured to neither allow hosting of custom codeapplications nor provide a test execution environment.

FIG. 4 provides a high-level representation of principal phases of anautomatic test generation process in accordance with the disclosure.

FIGS. 5-11 are screenshots of exemplary user interfaces generated by thetest specification/generation user interface during a scenariospecification phase.

FIG. 12 is a flowchart of a sequence of operations performed during ascenario generation phase in accordance with the disclosure.

FIGS. 13 and 14 are screenshots of exemplary user interfaces presentedto a user during the period in which a test generator is actuallyperforming processing operations to generate a test suite.

FIG. 15 is a screenshot of an exemplary user interface signaling thattest generation operations have been completed and a set of tests havebeen added to a test suite.

FIG. 16 is a screenshot of an exemplary user interface containing a listof tests included within the test suite identified in FIG. 15.

FIG. 17 is a screenshot of a user interface produced by a testgeneration user interface which illustrates a test suite consisting ofgenerated tests produced by the test generation system of thedisclosure.

FIG. 18 is a screenshot of a user interface produced by the testgeneration user interface which shows an example of a test generated bythe test generation system of the disclosure.

FIG. 19 is a screenshot of a user interface produced by the testgeneration user interface which shows a detailed view of test stepRecord Validation included within the test shown in FIG. 18.

FIG. 20 is a screenshot of a user interface generated by the testgeneration user interface that is associated with test execution withina separate test execution environment.

FIG. 21 illustrates a one-to-one relationship between a record undertest and a related record referenced by the record under test.

FIG. 22 illustrates a one-to-many relationship between related recordsand a record under test.

DETAILED DESCRIPTION Architecture

In one embodiment the test generation system of the present disclosureis architected to support the impersonation of a human user of anapplication being tested and the collection of results of simulatedinteraction of the impersonated user with the application. Morespecifically, the test generation system is implemented in an executionenvironment and is preferably configured to impersonate users, takeactions in user interfaces accessible to such users, and gathersimulation information about the system behavior resulting fromexecution of the application on a first version of a hosting platform. Aprocess model of the application may then be determined based upon thesimulation information. Tests created by the test generation system maybe loaded in the same, or a different, execution environment.

In one embodiment the software application is tested on a second versionof the hosting platform and resulting test results are recorded. Aregression or other defect in the software application may then bydetermined by identifying one or more differences between the recordedtest results and the simulation information

Architecture: Execution Environment

Attention is directed to FIG. 1A, which illustratively represents anexemplary architecture of a test generation system 100 configured toautomatically test an application 148 written on a SaaS platform. Thesystem 100 includes a PaaS environment 110, a test generation system 120and a test execution environment 130. As shown, the PaaS environment 110includes a PaaS backend server(s) and database arrangement (“PaaSbackend”) 134 in communication through a network 140 such as theInternet with a mobile device 142 executing a Web browser 144. Duringoperation of the system 100, the Web browser 144 renders a userinterface 149 of the application 148 being tested.

In one embodiment the test execution environment 130 runs within thePaaS environment 110. Alternatively, the test execution environment 130can run in a stand-alone execution environment separate from the PaaSenvironment 110. Implementations of the test execution environment 130within the PaaS environment 110 can leverage, to the extent that theyare available, extensibility points provided by the platform. Someimplementations of the PaaS environment 110 provide close to unlimitedsupport for extensibility, in the form of the ability to injectarbitrary code that should be executed on the PaaS backend server(s) anddatabase arrangement 134 and on the mobile device 142 and/or Web browser144. Other SaaS/PaaS may be more limited in the extensibility pointsthey expose, perhaps only providing customization through GUI's (notcode).

If the PaaS environment 110 provides a fully functional code executionenvironment, then the test generation system 120 can be hosted in thePaaS environment 110; otherwise, the test generation system 120 ishosted separately from the PaaS environment 110. The implementation issimilar in either case. The test generation system 120 leverages acustom webpage (HTML and client-side JavaScript) as the entry-point togenerating tests. The page hosts a test specification user interface 150for selecting what tests to create. Once the tests to be created havebeen specified this same page hosts the information gatheringfunctionality. In one embodiment the information gathering works byopening the pages to be tested in an iframe that can be controlled fromthe outer frame. The iframe is pointed to the form or other page to betested. JavaScript embedded in the outer page automates the actionstaken on the page being tested. Actions are taken against the page andinformation is gathered, all via API calls made from the outer frameagainst the iframe. This information is collected and used duringscenario generation eventually resulting in the test generator 160generating a test in the test execution environment 130. The serverexecution environment for the test generation system 120, if not runningon the PaaS environment 110, may be any back-end for Web applications.The main requirement is that such a server execution environment shouldbe capable of serving HTTP requests as well as integrating with the testexecution environment 130 for the purpose of loading tests.

FIGS. 1B and 1C illustrate an exemplary process flow 200 associated withthe test generation system 100 of the present disclosure. Specifically,FIG. 1B illustrates the process flow 200 within the context of thearchitecture of the execution environment 100 of FIG. 1A, while FIG. 1Cis a flowchart representative of the process flow 200.

As shown in FIGS. 1B and 1C, the process flow 200 may be initiated whena testing professional or other user accesses the test specificationuser interface 150 and specifies the tests to be created (stage 204). Inone embodiment the test specification user interface 150 runs from theWeb browser 144 or from another Web browser within the PaaS environment110 (stage 210). Upon completion of a test specification, the testspecification user interface 150 triggers the test generator 160 (stage216). The test generator 160 may execute within the same Web browserhosting the test specification user interface 150 or in a separate Webbrowser depending on constraints of the PaaS environment 110 to hostarbitrary user interfaces (in cases in which the PaaS environment 110hosts the test generation system 120) (stage 222). The test generator160 then proceeds to impersonates users, takes actions against userinterface pages 149 of the application under test 148, and storesinformation about system behavior after every action (stage 230). Thetest generator 160 also outputs the test which it has developed into thetest execution environment 130 (stage 236). In one embodiment the testis comprised of a sequence of steps where some or all of the stepsconsist of actions and assertions as determined during test generation.The test provided by the test generator 160 is then executed within thetest execution environment 130 in the same way in which other testswould be executed (stage 242).

FIG. 2 is a diagram of an exemplary architecture of a PaaS environment110′ lacking constraints on hosting arbitrary code or customapplications. In the architecture of FIG. 2 the PaaS backend 134′ isconfigured to provide the test execution environment.

FIG. 3 is a diagram of an alternative exemplary architecture of a PaaSenvironment 110″ that is configured to neither allow hosting of customcode applications nor provide a test execution environment 130″. In thisconfiguration a separate HTTP test generation server 310 is used to hostthe test generation system 120. In addition, the test generation system120 writes tests into a standalone off-the-shelf test executionenvironment 130″ (e.g., a Selenium environment).

Architecture: User Impersonation

In one embodiment the test generation makes heavy use of impersonationof users on the PaaS. The only requirement is the need to setup asession with the PaaS for a given user. If the PaaS environment providesthe ability to impersonate another user as a feature than the testgeneration system can just use it. Otherwise it can be accomplished byautomating the interactions with a login form. In the absence of animpersonation feature the system can set the password of the user itneeds to impersonate and then instruct the iframe where test generationis running to access the login page, enter the username and password atwhich point the session cookie for the iframe will be set for the userto be impersonated. At this point the test generation system cannavigate user interfaces with the permissions (behavior and accesslevel) of the user being impersonated. Some PaaS implement extensibilitypoints for controlling user authentication. This may also provide anoption for implementing impersonation without necessitating manipulatingpasswords attached to user accounts. Finally depending on constraints ofthe PaaS relative to browser cross-site scripting security constraintsit may be necessary to use two separate web browsers, one hosting theuser interface for Scenario Specification and the other, remotecontrolled actually doing information gathering.

Architecture: Historical Data, Audit Logs and Record Created/UpdatedDate Stamps

In one embodiment the test generation system makes use of historicaldata and audit logs in order to inform the test generation process.Historical data is referenced for providing valid form inputs that areknown to have passed data-validation rules in the past. During recordvalidation audit data is used to identify when a field was set so thatrecord validations are limited to asserting only against field valuesset as a result of an action taken against the record under test.

Most PaaS systems have built-in audit logs and allow programmaticaccess. In a system with audit logs they are used as provided by thePaaS. In the absence of audit logs built into the PaaS the audit logscan be implemented from scratch to meet the requirements of the testgeneration system.

Architecture: PaaS APIs, Required Extensibility Points and WorkaroundsForm API's Schema APIs Record APIs Architecture: Test Loading

Test loading will vary depending on the test execution environment.

Attention is now directed to FIG. 4, which provides a high-levelrepresentation of principal phases of an automatic test generationprocess in accordance with the disclosure. As shown in FIG. 4, thesesequential phases include a scenario specification phase 410, a scenariogeneration phase 420 and a test execution phase 430. In the scenariospecification phase 410, a testing professional provides a high levelspecification of the tests to be generated. Specifically, the testingprofessional provides inputs identifying objects 168 to test withrespect to specified users. The scenario generation phase 420 includesautomated generation of tests based upon the test specificationsprovided during the scenario specification phase 410. In one embodimenta principal objective of the automated tests generated during this phaseis determination of the current business process associated with theapplication under test 148. The test execution phase 430 includesexecuting a scenario developed during the scenario generation phase 420as a test. The scenarios generated during the scenario generation phase420 are preferably generated such the test scenario fails upon executionif the business process associated with the user interfaces 149 of theapplication 148 being tested has changed or is no longer functional.

As is discussed further below, FIGS. 5-11 are screenshots of exemplaryuser interfaces generated by the test specification/generation userinterface 150 during the scenario specification phase 410.

Scenario Specification

As discussed above with reference to FIG. 4, a first step in oneembodiment of the disclosed automated test generation process isspecification of the scenarios for which tests should be generated(stage 410). Generating tests with the system first requires input forwhat object, table or form and view/s 168 of the application 148 are tobe tested. See, e.g., FIGS. 5 and 6, which are exemplary user interfacespresented by the test specification user interface 150 through whichbase-tables of the application 148 may be selected for testing. FIGS. 7and 8 are exemplary user interfaces presented by the test specificationuser interface 150 during gathering of data relating to the selectedbase-tables.

FIG. 9 is a screenshot of the exemplary user interface 900 generated bythe test specification user interface 150 which presents variousselectable table and role combinations selectable from which tests maybe generated.

As shown in the user interface of FIG. 10, in one embodiment the testingprofessional may specify whether a test is to be created for eachtable/user on every form view for the table or just for the default viewof the user.

Another key variable to be specified for each scenario is the set ofusers that should be impersonated when testing. Different user accountswill have different privileges in the application under test 148depending on, for example, security rules (access controls) and theaccess levels assigned to the user (roles).

Referring to the exemplary user interface of FIG. 11, in one embodimenta new test suite is created based upon the scenario specificationparameters provided by the testing professional.

Scenario Specification: User Grouping

By grouping users by their roles the test generation system 120streamlines scenario specification. User grouping starts from the tableor object under test 168 specified through the test specification userinterface 150. In one embodiment the system 120 issues a group-by queryto the PaaS backend 134 in order to divide recently created records 170by the user responsible for creating the record and select the count ofrecords 170 created as a result of activity by that user. Next, for eachuser the system 120 queries user attributes 180 for that user. Relevantattributes could be anything tied to a user likely to affect behavior ofthe application 148, but generally relates to their security roles orpermissions. Attributes are serialized and used to generate a key 184that can be used to index into a map 188. For each user a map 188 isqueried by the user attribute key 184, if there already exists an entryin the map 188 for the user attribute key then the count of records 170created for that user is added to the existing total for that map entry.Otherwise a new entry is created in the map 188 for that key 184 withits starting value for the count set equal to the count for the currentuser. An overall total count of records 170 is also tracked. After allusers have been indexed into the map 188 by their user attributes, themap 188 is transformed to a list of groupings sorted by count. Each listentry contains: a user readable definition of the key (list of roles),count, percent of total count (calculated by dividing the count for thegroup by the overall total count), and an example user that matches tothe key.

The example below provides a scenario specification for a table“incident” of an application 148 under test in which users are groupedby their roles. The specification is for a test based on a uniquecombination of roles that a user inserting a record to a given tablehas.

“table”:“incident”, “tableLabel”:“

”, “roleGroups”:

{

“table”:“

”, “roleCombo”:

“roleComboDisplay”:“

_service_user,

,

_

_

,

_

,

,

_

,

_

”, “roleGroupCount”:8

“exampleUsersName”:“

user”, “exampleUsersSysId”:“

”, “selected”:false }, {

“table”:“

”, “roleCombo”:“

”, “roleComboDisplay”:“

”, “roleGroupCount”:

“exampleUsersName”:“System Adimistrator”, “exampleUsersSysId”:“

”, “selected”:false } }, “tableCount”:1

indicates data missing or illegible when filed

Scenario Specification: Inputs Selection

While it may be desirable to generate tests for all possible scenarios,it is more than likely necessary to set some limits because there aretypically simply too many possible combinations of input variables tofeasibly test all possible combinations. Given that it may not bepractical to run or maintain tests for all possible scenarios,embodiments of the system 120 facilitate scenario specification byprioritizing groupings of tables and users with the same roles, sortingbased on historical number of records 170 created by users with thatgrouping of roles on that table.

Because the system 120 has information about past trends the user isable to make its determination of what tests to generate with relevanttest coverage information expressed as a percent for each grouping,where the percent relates what percentage of historical records thisscenario is representative of.

Scenario Generation

Turning now to FIG. 12, a flowchart is provided of a sequence ofoperations 1200 performed during a scenario generation phase inaccordance with the disclosure. In one embodiment the test generator 160initiates the scenario generation phase starts by logging in to theapplication under test 148 as an impersonated user (stage 1210). Theprocess of test generation during the scenario generation phasecontinues by leveraging API calls to gather information about the formor other user-interface being targeted by the test and automaticallysimulating the interactions of the impersonated user through API calls.For each action capable of being taken by the impersonated user, thetest generator 160 can simulate that action. For example, it is possibleto simulate actions through API calls corresponding to, for example,“Open a form”, “Set a value to a field”, or “Click a button”. We candetermine the effect of an action also by making API calls. Each time wetake a step we gather relevant information to determine the effect ofthat step. A typical flow for a form user-interface is 1) Open the formand gather information concerning: visible fields, mandatory fields,read-only fields, available actions (buttons) and current field values(stage 1220); 2) Determine if values have been set for all mandatoryfields (stage 1230) and, if not, set a mandatory field value (stage1240) and then again gather form information (stage 1250) as wasinitially done in stage 1220; 3) Keep setting all mandatory fields andgathering data until the form has been filled out with a minimal amountof information (stage 1230); 4) Submit the form (stage 1260); 5)Validate the resulting record 170/objects 168, as discussed furtherbelow (stage 1270).

As used herein, the term “mandatory field” means a field on a form thatmust be filled in in order for the form to be submitted to theapplication 148. As used herein, the term “multiple choice mandatoryfield” means a field on a form with a limited number of values. Thesefields are often used to determine the path that should be followed in abusiness process flow because they enumerate the possible values. Thisis in contrast to a field that has an infinite range of possible values(e.g., a description field).

This use of code to automate the interactions with the user interface149 of the application under test 148 enables regression tests capableof detecting the current behavior or business logic of the application148 to be automatically generated. As discussed above, the form isfilled out with only the minimal amount of information in order toimprove test coverage. In one embodiment the system 120 relies onhistorical information to populate the form (see: Scenario Generation:Historical precedence). However, such historical information may notindicate whether the particular field values were set by a user or byautomated rules/workflows that implement the application 148 under test.If the test specifies information that actually is set by automation,then it is possible to cover up an issue during test execution with theautomation that sets that field value, thus causing the test to miss aproblem. This outcome can be avoided in the manner described hereinafter(See, e.g., Record Validation).

Scenario Generation: Historical Precedence

In order to ensure that the system 120 will be able to successfullytraverse a process model of a business process or the like underlyingthe application 148, in one embodiment the test generation system 120relies on historical precedence. This ensures that to the extent theapplication 148 under test includes data validation logic, the testgeneration system 120 is not simply inputting random data but rather isinputting data that is known to have been successfully submitted in thepast. Information concerning valid inputs is collected by querying forhistorical records and/or audit data 192 (i.e., an example record withknown valid field values originally created by the user associated tothe current scenario), in case the validation rules are specific to thecurrent user type.

Scenario Generation: Scenario Enrichment

Automatic test generation can map out possible paths through the systemand further inform automated decisions as to the relevance of possiblechoices based on whether they cause changes in behavior of theapplication 148. The automatic test generation system 120 determinesthat a field is of particular significance and maps out each particularscenario. This process may be referred to as scenario enrichment. Theunderpinning of scenario enrichment is that certain actions takenactually represent an important branch, corresponding to conditionallogic in the business process. This is only used for actions with adiscrete (limited) number of possible inputs/actions.

As an example, the system 120 may determine that a field on a formcalled “Category”, when set to different predetermined values, has theeffect of causing additional fields to change their state, perhapsbecoming mandatory or appearing or disappearing from the formaltogether. Since in this case the “Category” field is displayed as adrop-down with a discrete list of possible values, it is possible forthe system 120 to try them all and observe the resulting behavior of theapplication 148.

In contrast, when setting a free-text field to different values thesystem 120 may determine the particular field value to be of littlesignificance to determining resulting business logic because no otherfields on the form change their behavior dependent on the value in thatfield. These are examples of how the automated test generation system120 can determine the importance of including a particular action in atest based on whether there is a corresponding reaction.

Scenario Generation: Scenario Description

Test steps for the application 148, which is written on a PaaS, can bedescribed in the metaphors and abstractions of that PaaS. For example,“Open a form”, “Set a field value”, “Submit form” and “Validate Record”are instances of actions that might have specific meanings for aparticular PaaS and that can be joined to create a test scenario.Application data as well as historical logging data and audit data 192can be used to inform the test generation system 120 as to whatscenarios are actually performed by users of a particular system. In oneembodiment the test generator 160 records lists of scenarios, eachconsisting of a list of ordered steps. For each ordered step there is alist of expected outcomes serialized to the format necessary to executein the test execution environment 130.

Below is an example from a simple serialized scenario consisting offield state and related assertions. The example specifies that a testshould be generated by the test generator 160 for the table “incident”included within the application 148. A user with user id:681b365ec0a80164000fb0b05854a0cd will be used for testing. Mandatoryfields of “caller_id” and “short description” serve as a specificationof both an assertion (the fields should be mandatory) and an action thatwill be taken, setting the values of those fields as per the“exampleValues” section. The entry “submittedSuccessfully” specifiesthat this should submit successfully using the default submit action(form button). The entries under “recordValidations” specify assertionsto occur following submission of the expected values in the record afterit has been saved to the database 134

{ { “0”:”incident”, “1”:”681b365ec0a80164000fb0b05854a0cd”,“2”:”dw_user_default”, “3”:”User's Default”; “4”:{ “formInspectorData”:{“visibles”:[ ], “mandatories”:[ “caller_id”, “short_description” ],“readOnlies”:[ ], “exampleValues”:{ “active”:{ “value”:”1”, “type”:null}, “approval”:{ “value”:”not requested”, “type”:null }, “caller_id”:{“value”:”46c1293aa9fe1981000dc753e75ebeee”, “type”:”reference” },“category”:{ “value”:”inquiry”, “type”:”string” }, “child_incidents”:{“value”:”0”, “type”:”integer” }, “company”:{“value”:”31bea3d53790200044e0bfc8bcbe5dec”, “type”:null },“escalation”:{ “value”:”0”, “type”:null }, “impact{: “value':”3”,“type”:null }, “incident_state”:{ “value”:”1”, “type”:”integer” },“knowledge”:{ “value”:”0”, “type”:null }, “made_sla”:{ “value”:”1”,“type”:null }, “notify”:{ “value”:”1”, “type”:”integer” }, “opened_at”:{“value”:”2018-11-27 00:02:03”, “type”:null }, “opened_by”:{“value”:”681b365ec0a80164000fb0b05854a0cd”, “type”:null }, “priority”:{“value”:”5”, “type”:null }, “reassignment_count”:{ “value”:”0”,“type”:null }, “reopen_count”:{ “value”:”0”, “type”:”integer” },“severity”:{ “value”:”3”, “type”:”integer” }, “short_description”:{“value”:”SAP Sales app is not accessible”, “type”:null }, “state”:{“value”:”1”, “type”:null }, “upon_approval”:{ “value”:”proceed”,“type”:null }, “upon_reject”:{ “value”:”cancel”, “type”:null },“urgency”:{ “value”:”3”, “type”:null } }, “submittedSucessfully”:true,“fieldsSet”:{ “short_description”:{ “type”:null, “value”:”SAP Sales appis not accessible”, “setValueRound”:0 }, “caller_id”:{“type”:”reference”, “value”:”46c1293aa9fe1981000dc753e75ebeee”,“setValueRound”:0 } }, “skipReason”:null }, ”recordAnalysis”:{”relatedRecords”:{ }, “current”:{ “table”:”incident”, “fields”:{“active”:{ “field”:”active”, “value”:”1”, “type”:”boolean” },“approval”:{ “field”:”approval”, “value”:”not requested”;“type”:”string” }, “caller_id”:{ “field”:”caller_id”,“value”:”46c1293aa9fe1981000dc753e75ebeee”, “type”:”reference” },“category”:{ “field”:”category”; “value”:”inquiry”; “type”:”string” },“child_incidents”:{ “field”:”child_incidents”, “value”:”0”,“type”:”integer” }, “company”:{ “field”:”company”,“value”:”31bea3d53790200044e0bfc8bcbe5dec”, “type”:”reference” },“escalation”:{ “field”:”escalation”; “value”:”0”, “type”:”integer” },“impact”:{ “field”:”impact”, “value”:”3”, “type”:”integer” },“incident_state”:{ “field”:”incident_state”, “value”:”1”,“type”:”integer” }, “knowledge”:{ “field”:”knowledge”, “value”:”0”,“type”:”boolean” }, “made_sla”:{ “field”:”made_sla”, “value”:”1”,“type”:”boolean” }, “notify”:{ “field”:”notify”; “value”:”1”,“type”:”integer” }, “opened_by”:{ “field”:”opened_by”,“value”:”681b365ec0a80164000fb0b05854a0cd”, “type”:”reference” },“priority”:{ “field”:”priority”, “value”:”5”, “type”:”integer” },“reassignment_count”:{ “field”:”reassignment_count”; “value”:”0”,“type”:”integer” }, “reopen_count”:{ “field”:”reopen_count”,“value”:”0”, “type”:”integer” }, “severity”:{ “field”:”severity”,“value”:”3”, “type”:”integer” }, “short_description”:{“field”:”short_description”; “value”:”SAP Sales app is not accessible”,“type”:”string” }, “state”:{ “field”:”state”; “value”:”1”,“type”:”integer” }, “sys_class_name”:{ “field”:”sys_class_name”,“value”:”incident”, “type”:”sys_class_name” }, “sys_created_by”:{“field”:”sys_created_by”, “value”::”itil”, “type”:”string” },“sys_domain”:{ “field”:”sys_domain”, “value”:”global”,“type”:”domain_id” }, “sys_domain_path”:{ “field”:”sys_domain_path”,“value”:”/”, “type”:”domain_path” }, “sys_mod_count”:{“field”:”sys_mod_count”, “value”:”0”, “type”:”integer” },“sys_updated_by”:{ “field”:”sys_updated_by”, “value”:”itil”,“type”:”string” }, “upon_approval”:{ “field”:”upon_approval”,“value”:”proceed”, “type”:”string” }, “upon_reject”:{“field”:”upon_reject”, “value”:”cancel”, “type”:”string” }, “urgency”:{“field”:”urgency”, “value”:”3”, “type”:”integer” } } }, “valid”:true } }}

Scenario Generation: False Positive Elimination and Scenario Reliability

In order to be sure that an automatically generated description of abusiness process is valid to be used as an automated test, in oneembodiment it is necessary to eliminate those things which arenon-deterministic in nature relative to the action being tested. Inorder to do this the test generator 160 may generates its description ofcurrent behaviors multiple times prior to the change and cull from itsdescriptions anything which varies in the multiple descriptionsgenerated before the change. An example of a change that would be culledis a process model or business logic dictating that the currentdate-time be written to a record. Since every subsequent run of the testwill have a new value for date-time field, this field is not somethingthat should be asserted as part of a test. As a consequence, in oneembodiment the test generation phase is preliminarily executed multipletimes and any fields or other items that vary among these executions areremoved from the assertion list to be utilized during the actual test ofthe application 148. The finalized description of the process model forthe application 148 that has had non-deterministic data removed is whatis ultimately used for test creation.

An additional measure taken to ensure that scenarios are accurate is“negative assertions”. Negative assertions specify when during scenariogeneration the test generation system 120 detects a failure. Whensupported by the targeted text execution environment 130, the testgeneration system 120 will assert that the scenario should fail. Anexample would be where clicking the submit button will result in afailure to submit, perhaps because of an accounted for data-validationrule. The purpose of this additional measure is to avoid generatingtests that would fail due to shortcomings in the ability of the testgeneration system 120 to determine some required detail of the scenario.

In some cases Field Type Specific Value Transformations are used toensure scenarios are valid. An example is for date fields where valuesare relativized to the current date and time. This helps with a fieldvalidation on these fields that may be looking for a date in the futureor in the past. Relativizing means taking the date in the field andfinding and off-set from the time when the record was created (+/−somenumber of seconds) and then applying the offset to set the field in thescenario.

FIGS. 13-16 are screenshots of exemplary user interfaces generated bythe test specification/generation user interface 150 during the scenariogeneration phase 420. Specifically, FIGS. 13 and 14 are screenshots ofexemplary user interfaces presented to a user during the period in whichthe test generator 160 is actually performing processing operations togenerate a test suite. FIG. 15 is a screenshot of an exemplary userinterface signaling that these test generation operations have beencompleted and a set of tests have been added to a test suite 1510 named“Test Suite”. FIG. 16 is a screenshot of an exemplary user interface1600 containing a list of tests 1610 included within the test suite1510.

Test Execution

Test execution may be performed either by an existing test executionenvironment 130 separate from the automated test generation system 120or within the automated test generation system 120

FIG. 17 is a screenshot of a user interface 1700 produced by the testgeneration user interface 150 which illustrates a test suite consistingof generated tests produced by the test generation system 120.

FIG. 18 is a screenshot of a user interface 1800 produced by the testgeneration user interface 150 which shows an example of a specific test1710 included with test suite of FIG. 17. The test 1710 represented bythe user interface 1800 is defined in a domain specific language (DSL)and consists of a set of steps (database record per step) performed withrespect to the table Incident in the application 148 under test. Thetest represented by FIG. 18 is initiated by an initial Impersonate step1810 which involves logging in to the application 148 under test byimpersonating a user. Next, a getCurrentTime step 1820 is performed inwhich the system 120 begins listening for errors on the server 134. Inan Open a New Form step 1830 a new “Incident” form opened. The values onthe “Incident” form are then set consistent with the condition that “SAPsales app is not accessible” (stage 1840). The completed Incident formis then submitted in a Submit a Form step 1850. If errors were thrown inconnection with the execution of the test of FIG. 18, then Assert noserver errors is asserted (stage 1860). The test concludes with threeRecord Validation steps 1870, 1880, 1890 during which it is determinedwhether various records from the table Incident match certain conditions(i.e., “Active=true”, “Approval=Not Yet Requested” and “Caller=CarolCoughlin”).

FIG. 19 is a screenshot of a user interface 1900 produced by the testgeneration user interface 150 which shows a detailed view of test stepRecord Validation 1870 included within the test shown in FIG. 18.

Test Execution: Within the Test Generation System

The test generation system 120 is able to function as a test executionenvironment 130 when it generates the description (see “Simpleserialized scenario example” above) before and after a change in thePaaS underlying the application 148 under test and then compares theresults. If any action that is part of a given scenario results in adifferent assertion list when the scenario is executed on differentPaaS, then a test failure is deemed to exist. This is because existingbusiness processes have been found to have changed following a change inthe platform. In one embodiment the process for noticing a difference isthe same as that used for detecting non-deterministic data in theassertion list. Additionally, however, during test execution the system120 deals differently with actions. During the test generation phase420, when the system 120 determines that an action isn't possible theresulting test should assert this negative (see “Scenario Generation:False positive elimination and scenario reliability”).

Test Execution: Within a Separate Execution Environment

While it is possible for the test generation system 120 to also act asthe test execution environment 130, it is generally more advantageous touse a pre-existing test execution environment. One reason this may beadvantageous is that by using a pre-existing environment as the testexecution environment 130 a testing professional may be able to takeadvantage of consolidated and robust error reporting. Additionally, ifimported into a pre-existing testing framework, the tests generated bythe system 120 become editable and maintainable by testingprofessionals. They can thus be augmented with additional steps andfunctionality beyond what was generated by the testing system 120. Thisis particularly relevant when the test generation system 120 is beingused to bootstrap automated tests in cases in which the application 148was implemented without writing automated tests, thus requiring thatautomated tests be generated after the application 148 has beendeveloped and otherwise implemented.

The data collected during generation, actions and correspondingassertions, about the behavior of the system can be used to generatetests for a variety of different test execution environments. Mostautomated testing frameworks currently in existence provide the abilityto author a test as computer code by concatenating strings. Through theuse of code generation a test can be automatically written in thetesting framework requisite programming language that implements thetesting steps and assertions. Additionally, the test may be implementedas an automatically created test in a Domain Specific Language (DSL).The DSL may operate at a higher level of abstraction from a traditionalprogramming language and have specialized syntax or even user interfacesfor describing a test. These can also be generated programmatically. TheDSL for the tests need not be string based. If, for a given executionenvironment, the creation of tests is mediated through a user interfacethat writes database records, then the test generation may consist ofwriting structured data to a database. See, e.g., the screenshot of FIG.17, which lists example tests from an exemplary PaaS.

FIG. 20 is a screenshot of a user interface 2000 generated by the testgeneration user interface 150 that is associated with test executionwithin a separate test execution environment 130.

Test Execution: Error Detection

Thus far the automated test generation system 120 and associated testexecution process has been described in terms of its ability to detectbehavior differences: “When you do this, this other thing happens”.Another important determination of testing success is system errors.System errors occur when an exception is thrown from the code orunderlying runtime for the PaaS. Net new errors are recorded as testfailures in addition to behavioral changes. The two may go hand in hand;that is, the system changed behavior because an underlying erroroccurred in the code. Errors can be detected by accessing logs eithervia an API or scraping logs. The system 120 automatically detects errorsin the Web browser 144 by overriding the JavaScript API's for writinglog messages prior to beginning the test and then listening for errors.A similar approach may be used on the server 134 and, additionally, logtables/files may be directly read with automation.

Any errors detected during test generation are simply recorded. Anyerrors detected during test execution are compared against thosedetected during test generation and in one embodiment the test is failedif the error is net-new.

While the detection of errors during a test execution is known, theability to generate a test automatically and then detect errors asdescribed herein is novel and important since this capability providesenhanced test coverage in addition to the detection of behavior changeswith explicit assertions.

Record Actions and Validation

In addition to the assertion criteria already mentioned, the automatedtest generation system 120 also observes for side-effects that can beused as assertion criteria. These are parts of the business processimplemented by the application 148 which do not manifest until after aform is submitted. These include a record 170 or object 168 directlyresulting from the submission of the form as well as other records 170besides the one upon which actions are being directly taken. In order todetect side-effects to other records objects 168, the system 120 willpreferably follow referential data in the database 134. In particular,when generating tests the test generation system 120 will observe anyrecords 168 referenced by a foreign key relationship from the recordunder test. It will also query for any foreign key relationshipspointing back to the record under test.

Record Actions and Validation: Validation of Record Under Test

The “record under test” is the primary record 170 corresponding to theform of the application 148 that was open and submitted during testgeneration and later test execution. During test generation, a set ofassertions are generated for what field values should be expectedfollowing submission of the record under test. In one embodiment thesame process is followed twice during test generation to submit arecord. The field values resulting from these two runs are thencompared. Any field values that differ between the two runs are not usedin an assertion as these are determined to be non-deterministic innature. An example of a field that is determined to be non-deterministicwould be a field tracking the time the record was created. The time willbe different for each subsequent submission and thus any given timevalue will not be repeatable. In one embodiment the set of assertions iscompiled into steps, at the end of the generated test, which query therecord just inserted by the actions taken within the UI and assert eachfield value on that record.

Record Actions and Validation: One-to-One Relations, Reference fromRecord Under Test

Attention is now directed to FIG. 21, which illustrates a one-to-onerelationship between a record under test 2110 and a related record 2120referenced by the record under test. Referring to FIG. 21, one to onerelations for records referenced from the record under test 2110 aredetected and validated. For all fields 2112 on the record being tested,if the field 2112 stores a foreign key relationship, that record isqueried. If the record was updated or inserted as a side-effect of thesubmission of the “Record for test”, then the fields are recorded.Whether the record was created or updated can be determined by lookingat “Creation date”, “Last updated date” or audit data. During the secondgeneration (scenario is repeated at least twice as noted previously) thefields are also recorded and then compared to what was recorded for theprevious run. Any fields found to vary are culled from the list ofrecorded fields. This is necessary to remove any non-deterministicvalues for which a value should not be inserted. For example, a fieldfor the created date cannot be part of the record assertion because itwill vary for each record. This data becomes an assertion/s in thescenario. During test execution, the test for the scenario will assertthat the field contains a valid reference. If the record was found tohave been created then the field values are asserted based on the listof field values observed to be deterministic in nature at test creationtime. If the record was only updated then only fields with values thatchanged as part of that update, as determined by referencing audit data(see Architecture: Historical data, audit logs and recordcreated/updated date stamps) will be recorded.

Record Actions and Validation: One-to-Many Relations, Reference toRecord Under Test

Attention is now directed to FIG. 22, which illustrates a one-to-manyrelationship between related records 2210 and a record under test 2220.In particular, FIG. 22 shows that one-to-many relations from relatedrecords 2210 referencing the record under test 2220 are also detectedand validated. In order to validate records related by a one to manyrelationship, the test generation system 120 needs to identifydeterministic characteristics for these records; that is, values thatwill be present consistently for executions of the to-be generated test.In one embodiment this works as follows. The test generator 160 runs thesteps that will result in submission of a record twice. Each time everyfield on every table that stores a reference (foreign key relationship)back to the table of the record under test 2220 is queried. The querylooks for the ID to be the record under test 2220. The count of recordsis added to the list of assertions and the eventual test will laterassert that count. Additionally, all of the field values are stored.Upon the second run, still part of single test generation, the testgenerator 160 performs the same queries again. In cases where there aremultiple records 2210 referencing the record under test 2220, from thesame table and field combination, the test generator 160 needs to matchlike records between runs. This is accomplished by comparing each recordfrom each execution run with all records from the other generation run.The output of this comparison is a similarity score. Each record ismatched to the record with which it is determined it has the highestsimilarity scoring. The similarity scoring can be ascertained usingstring comparison scoring like that implemented by, for example:https://github.com/mhutter/string-similarity. After determining the mostsimilar record, any differences between the matched records are culledso that the assertion only contains those fields which were the samebetween the two scenario generation runs. The resulting serializedrecord is used to create an assertion for the test for any fields thatremain. The assertion at test execution time is implemented as a queryagainst the related table, with each field assertion included as a termin the query's where clause.

Record Actions and Validation: Many-to-Many Relations to Record UnderTest

Validation of many to many tables happens with a recursively executedcombination of the one-to-one and one-to-many validations. For everyrecord detected via the process for one-to-one or one-to-many, thesystem 120 then also checks its relations. In this way it is possible tomap out all the side-effects that resulted from the action taken on theoriginal object 168. This is illustrated by the following example.Consider that the record under test may be part of a request forpurchase application. Upon submission of the request for purchase,multiple records 170/objects (one-to-many) are inserted into a databasetracking individual approvals necessary before the request is approved,with each approval having a reference back to the purchase request. Eachapproval may trigger the sending of an email which is logged to a tablewhere the email links back to the corresponding approval record. Becausethe discovery of related records operates recursively, the system 120 isable to detect the relationship all the way to the email log record (notjust to the approval).

Related Uses Beyond Functional Testing Performance Testing

In addition to validating that an application 148 under test is workingfunctionally after an upgrade to the SaaS Platform, the approachdisclosed herein may be leveraged for the purposes of performancetesting. Specifically, by adding test steps that implement timers tomeasure the time required by the application 148 to execute thegenerated test scenarios, the system 120 may be configured to providevalidation that the scenario completes without a regression in terms ofthe speed with which the user interface 149 renders and responds. Forthis purpose the test generation system 120 executes the same actionmultiple times, and collects multiple samples of time for scenariobefore and after in order to correct for variability in the results.

While various embodiments have been described above, it should beunderstood that they have been presented by way of example only, and notlimitation. They are not intended to be exhaustive or to limit theclaims to the precise forms disclosed. Indeed, many modifications andvariations are possible in view of the above teachings. The embodimentswere chosen and described in order to best explain the principles of thedescribed systems and methods and their practical applications, theythereby enable others skilled in the art to best utilize the describedsystems and methods and various embodiments with various modificationsas are suited to the particular use contemplated.

Where methods described above indicate certain events occurring incertain order, the ordering of certain events may be modified.Additionally, certain of the events may be performed concurrently in aparallel process when possible, as well as performed sequentially asdescribed above. Although various modules in the different devices areshown to be located in the processors of the device, they can also belocated/stored in the memory of the device (e.g., software modules) andcan be accessed and executed by the processors. Accordingly, thespecification is intended to embrace all such modifications andvariations of the disclosed embodiments that fall within the spirit andscope of the appended claims.

The foregoing description, for purposes of explanation, used specificnomenclature to provide a thorough understanding of the claimed systemsand methods. However, it will be apparent to one skilled in the art thatspecific details are not required in order to practice the systems andmethods described herein. Thus, the foregoing descriptions of specificembodiments of the described systems and methods are presented forpurposes of illustration and description. They are not intended to beexhaustive or to limit the claims to the precise forms disclosed;obviously, many modifications and variations are possible in view of theabove teachings. The embodiments were chosen and described in order tobest explain the principles of the described systems and methods andtheir practical applications, they thereby enable others skilled in theart to best utilize the described systems and methods and variousembodiments with various modifications as are suited to the particularuse contemplated. It is intended that the following claims and theirequivalents define the scope of the systems and methods describedherein.

The various methods or processes outlined herein may be coded assoftware that is executable on one or more processors that employ anyone of a variety of operating systems or platforms. Additionally, suchsoftware may be written using any of a number of suitable programminglanguages and/or programming or scripting tools, and also may becompiled as executable machine language code or intermediate code thatis executed on a framework or virtual machine.

Examples of computer code include, but are not limited to, micro-code ormicro-instructions, machine instructions, such as produced by acompiler, code used to produce a web service, and files containinghigher-level instructions that are executed by a computer using aninterpreter. For example, embodiments may be implemented usingimperative programming languages (e.g., C, Fortran, etc.), functionalprogramming languages (Haskell, Erlang, etc.), logical programminglanguages (e.g., Prolog), object-oriented programming languages (e.g.,Java, C++, etc.) or other suitable programming languages and/ordevelopment tools. Additional examples of computer code include, but arenot limited to, control signals, encrypted code, and compressed code.

In this respect, various inventive concepts may be embodied as acomputer readable storage medium (or multiple computer readable storagemedia) (e.g., a computer memory, one or more floppy discs, compactdiscs, optical discs, magnetic tapes, flash memories, circuitconfigurations in Field Programmable Gate Arrays or other semiconductordevices, or other non-transitory medium or tangible computer storagemedium) encoded with one or more programs that, when executed on one ormore computers or other processors, perform methods that implement thevarious embodiments of the invention discussed above. The computerreadable medium or media can be transportable, such that the program orprograms stored thereon can be loaded into one or more differentcomputers or other processors to implement various aspects of thepresent invention as discussed above.

The terms “program” or “software” are used herein in a generic sense torefer to any type of computer code or set of computer-executableinstructions that can be employed to program a computer or otherprocessor to implement various aspects of embodiments as discussedabove. Additionally, it should be appreciated that according to oneaspect, one or more computer programs that when executed perform methodsof the present invention need not reside on a single computer orprocessor, but may be distributed in a modular fashion amongst a numberof different computers or processors to implement various aspects of thepresent invention.

Computer-executable instructions may be in many forms, such as programmodules, executed by one or more computers or other devices. Generally,program modules include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Typically the functionality of the program modulesmay be combined or distributed as desired in various embodiments.

Also, data structures may be stored in computer-readable media in anysuitable form. For simplicity of illustration, data structures may beshown to have fields that are related through location in the datastructure. Such relationships may likewise be achieved by assigningstorage for the fields with locations in a computer-readable medium thatconvey relationship between the fields. However, any suitable mechanismmay be used to establish a relationship between information in fields ofa data structure, including through the use of pointers, tags or othermechanisms that establish relationship between data elements.

Also, various inventive concepts may be embodied as one or more methods,of which an example has been provided. The acts performed as part of themethod may be ordered in any suitable way. Accordingly, embodiments maybe constructed in which acts are performed in an order different thanillustrated, which may include performing some acts simultaneously, eventhough shown as sequential acts in illustrative embodiments.

All definitions, as defined and used herein, should be understood tocontrol over dictionary definitions, definitions in documentsincorporated by reference, and/or ordinary meanings of the definedterms.

The indefinite articles “a” and “an,” as used herein in thespecification and in the claims, unless clearly indicated to thecontrary, should be understood to mean “at least one.”

The phrase “and/or,” as used herein in the specification and in theclaims, should be understood to mean “either or both” of the elements soconjoined, i.e., elements that are conjunctively present in some casesand disjunctively present in other cases. Multiple elements listed with“and/or” should be construed in the same fashion, i.e., “one or more” ofthe elements so conjoined. Other elements may optionally be presentother than the elements specifically identified by the “and/or” clause,whether related or unrelated to those elements specifically identified.Thus, as a non-limiting example, a reference to “A and/or B”, when usedin conjunction with open-ended language such as “comprising” can refer,in one embodiment, to A only (optionally including elements other thanB); in another embodiment, to B only (optionally including elementsother than A); in yet another embodiment, to both A and B (optionallyincluding other elements); etc.

As used herein in the specification and in the claims, “or” should beunderstood to have the same meaning as “and/or” as defined above. Forexample, when separating items in a list, “or” or “and/or” shall beinterpreted as being inclusive, i.e., the inclusion of at least one, butalso including more than one, of a number or list of elements, and,optionally, additional unlisted items. Only terms clearly indicated tothe contrary, such as “only one of” or “exactly one of,” or, when usedin the claims, “consisting of,” will refer to the inclusion of exactlyone element of a number or list of elements. In general, the term “or”as used herein shall only be interpreted as indicating exclusivealternatives (i.e. “one or the other but not both”) when preceded byterms of exclusivity, such as “either,” “one of,” “only one of” or“exactly one of.” “Consisting essentially of” when used in the claims,shall have its ordinary meaning as used in the field of patent law.

As used herein in the specification and in the claims, the phrase “atleast one,” in reference to a list of one or more elements, should beunderstood to mean at least one element selected from any one or more ofthe elements in the list of elements, but not necessarily including atleast one of each and every element specifically listed within the listof elements and not excluding any combinations of elements in the listof elements. This definition also allows that elements may optionally bepresent other than the elements specifically identified within the listof elements to which the phrase “at least one” refers, whether relatedor unrelated to those elements specifically identified. Thus, as anon-limiting example, “at least one of A and B” (or, equivalently, “atleast one of A or B,” or, equivalently “at least one of A and/or B”) canrefer, in one embodiment, to at least one, optionally including morethan one, A, with no B present (and optionally including elements otherthan B); in another embodiment, to at least one, optionally includingmore than one, B, with no A present (and optionally including elementsother than A); in yet another embodiment, to at least one, optionallyincluding more than one, A, and at least one, optionally including morethan one, B (and optionally including other elements); etc.

In the claims, as well as in the specification above, all transitionalphrases such as “comprising,” “including,” “carrying,” “having,”“containing,” “involving,” “holding,” “composed of,” and the like are tobe understood to be open-ended, i.e., to mean including but not limitedto. Only the transitional phrases “consisting of” and “consistingessentially of” shall be closed or semi-closed transitional phrases,respectively, as set forth in the United States Patent Office Manual ofPatent Examining Procedures, Section 2111.03.

What is claimed is:
 1. A computer-implemented method of mapping aprocess model of a software application executed by a hosting platform,the software application being based on a plurality of records, themethod comprising: simulating, through one or more applicationprogramming interface (API) calls, a series of actions taken by a userwith respect to one or more user interfaces generated by the softwareapplication wherein the one or more user interfaces include at least oneform and the series of actions includes opening the form; identifying,through one or more other API calls executed while impersonating asession of a user under test, a plurality of user interface fields ofthe form, the series of actions further including setting one or more ofthe plurality of user interface fields to known values and submittingthe form to the software application subsequent to the setting of theone or more of the user interface fields; gathering field-relatedinformation resulting from the setting of the plurality of userinterface fields; gathering record-related information corresponding toone or more effects on the plurality of records resulting from thesubmission of the form; and determining the process model based upon thefield-related information and the record-related information.
 2. Themethod of claim 1 wherein the identifying the plurality of userinterface fields includes identifying one or more visible fields, one ormore mandatory fields, and one or more read-only fields.
 3. The methodof claim 1 wherein the identifying the plurality of user interfacefields includes identifying one or more available actions.
 4. The methodof claim 1 further including identifying current field values of ones ofthe plurality of user interface fields, the current field values beingincluded within the field-related information.
 5. The method of claim 1wherein a plurality of mandatory fields are included within theplurality of user interface fields is, the setting of the one or more ofthe fields including setting only the plurality of mandatory fields. 6.The method of claim 1 wherein the series of actions are included withina plurality of scenarios, each of the plurality of scenarios beingautomatically generated based upon one of a plurality of scenariospecifications.
 7. The method of claim 6 wherein at least one of thescenario specifications includes information specifying which objects ofthe software application are to be tested with respect to at least oneof a set of users or a set of user groups.
 8. The method of claim 1wherein the known values are obtained from historical data relating toprior usage of the software application. claim Set #2 (automated testingbased on business process model)
 9. A computer-implemented method ofautomated testing of a software application executed against a hostingplatform, the method comprising: determining a process model of thesoftware application based upon user interface (UI) field-relatedinformation and record-related information obtained by simulating,through one or more application programming interface (API) calls, aseries of actions taken by a user with respect to one or more userinterfaces generated by the software application when executing on afirst version of the hosting platform; automatically generating a testof the software application based upon the process model; and testingthe software application in accordance with the test when the softwareapplication is executing on a second version of the hosting platform.10. The method of claim 9 wherein the one or more user interfacesinclude at least one form and the series of actions includes opening theform.
 11. The method of claim 10 wherein the determining the processmodel further includes: identifying, through one or more other APIcalls, a plurality of user interface fields of the form, the series ofactions further including setting one or more of the plurality of userinterface fields to known values and submitting the form to the softwareapplication subsequent to the setting of the one or more of the userinterface fields; gathering the field-related information wherein thefield-related information results from the setting of the plurality ofuser interface fields; gathering the record-related information whereinthe record-related information corresponds to one or more effects on theplurality of records resulting from the submission of the form.
 12. Themethod of claim 11 wherein the identifying the plurality of userinterface fields includes identifying one or more visible fields, one ormore mandatory fields, and one or more read-only fields.
 13. The methodof claim 11 wherein the identifying the plurality of user interfacefields includes identifying one or more available actions.
 14. Themethod of claim 11 further including identifying current field values ofones of the plurality of user interface fields, the current field valuesbeing included within the field-related information.
 15. The method ofclaim 11 wherein a plurality of mandatory fields are included within theplurality of user interface fields is, the setting of the one or more ofthe fields including setting only the plurality of mandatory fields. 16.The method of claim 11 wherein the series of actions are included withina plurality of scenarios, each of the plurality of scenarios beingautomatically generated based upon one of a plurality of scenariospecifications.
 17. The method of claim 16 wherein at least one of thescenario specifications includes information specifying which objects ofthe software application are to be tested with respect to at least oneof a set of users or a set of user groups.
 18. The method of claim 9wherein the testing includes executing a plurality of pass/fail tests.19. The method of claim 9 wherein the testing includes: recording testresults resulting from the testing of the software application; anddetecting a regression in the software application by identifying one ormore differences between the test results and initial simulation resultscomprised of the UI field-related information and the record-relatedinformation.
 20. The method of claim 9 wherein the one or more userinterfaces include at least one form, the determining the process modelfurther including identifying, through one or more other API calls, aplurality of user interface fields of the form.
 21. The method of claim20 further including determining ones of the plurality of user interfacefields corresponding to mandatory fields wherein the series of actionsincludes setting only the mandatory fields to known values.
 22. Themethod of claim 11 wherein the setting of the one or more of the userinterface fields includes using known values obtained from historicaldata relating to prior usage of the software application.